Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/api/chat/stream/route.ts`:
- Line 41: currentSystemPrompt is passed directly to researcher and never
augmented with RAG context; call the RAG augmentation flow (use the functions
from lib/actions/rag.ts such as generate_embedding and hybrid_search or your
existing wrapper that returns augmentedSystemPrompt) after fetching
getSystemPrompt(userId) and before invoking researcher, then pass
augmentedSystemPrompt to researcher instead of currentSystemPrompt (reference
symbols: currentSystemPrompt, getSystemPrompt, researcher, generate_embedding,
hybrid_search, augmentedSystemPrompt).
- Around line 45-56: The current mapping that builds messages (variable messages
from clientMessages) strips tool-related data by filtering only roles
'user'|'assistant' and mapping to {role, content}, which loses
assistant.toolInvocations and drops any role === 'tool' turns; update the
construction of CoreMessage[] (the messages array creation) to preserve tool
turns and toolInvocations by: not filtering out role === 'tool', and when
mapping each item (from clientMessages) include toolInvocations and any other
auxiliary fields present on assistant messages (e.g., map to include role,
content, and toolInvocations when present), or add a short clarifying comment if
intentionally discarding tool data, so prior tool outputs and assistant tool
calls are replayed correctly.
- Around line 69-92: The hardcoded reply branch uses fragile exact-match logic
and inconsistent wording; update it to normalize the last user message (trim,
collapse whitespace, remove trailing punctuation and lowercase) before matching
instead of comparing raw lastText, and choose wording consistent with the system
prompt (use "Climate forecasting" everywhere) when building the definition
variable; also guard the branch by asserting messages.length > 0 (or
early-return) before accessing messages[messages.length - 1], and keep the call
to saveChatAsync(chatId, userId, messages, definition) after these checks;
alternatively consider moving these canned replies into the system prompt in
lib/agents/researcher.tsx and only use this branch as a fallback.
- Around line 195-272: handleResolutionSearch currently starts a ReadableStream
whose start callback can throw and those errors escape the outer try/catch, and
saveChatAsync is fire-and-forget; fix by making the stream start an async
function that wraps the body in try/catch/finally, calling controller.error(err)
on any caught error and ensuring controller.close() in success, and in finally
await saveChatAsync(chatId, userId, messages, analysisResult?.summary || '') (or
save an error marker) so chat persistence always runs; refer to
handleResolutionSearch, resolutionSearch, querySuggestor, saveChatAsync and use
controller.error(...) inside the start callback to propagate stream failures to
the response consumer.
- Around line 15-19: The 401 response in POST (app/api/chat/stream/route.ts ->
function POST) returns JSON body but omits Content-Type; update the Response
creation for the unauthorized branch to include the header "Content-Type:
application/json" (or use a JSON helper such as NextResponse.json) so the
response explicitly declares JSON content when returning the Unauthorized
payload.
- Around line 152-156: The main path calls querySuggestor with messages which
may still contain image parts; mirror the sanitisation used in
handleResolutionSearch by creating a sanitizedMessages (filtering out any
message.content parts with type 'image' or equivalent image payloads) and pass
that to querySuggestor instead of raw messages; update the relatedQueries
assignment (variable relatedQueries and call to querySuggestor) to use the
filtered messages so image data is never sent to querySuggestor.
- Around line 129-145: The loop in route.ts using researcher(...) can spin
indefinitely and compounds context because researcher mutates the shared
messages array; add a bounded retry mechanism (e.g., maxAttempts constant and an
attempts counter) and break the loop when attempts >= maxAttempts or when a
retry returns empty fullResponse N times (regardless of useSpecificAPI), and
ensure errorOccurred still influences exit where appropriate; also prevent
in-place mutation of messages by either passing a shallow copy of messages into
researcher(...) or refactoring researcher (in lib/agents/researcher.tsx) to
return the additional assistant/tool-turns instead of pushing them into the
provided messages array so retries don’t inflate context. Ensure you update
usages of answer, errorOccurred, and allToolOutputs accordingly so retries stop
after the maxAttempts and do not duplicate tool outputs.
- Line 113: The stream is sending annotation frames using the "8:[...]" prefix
so annotations end up on individual messages instead of in useChat's data field;
update every controller.enqueue(encoder.encode(`8:[${JSON.stringify(...) }]\n`))
call (the ones emitting tool_result, inquiry, related, resolution_search_result
payloads) to use the data-frame prefix "2:[...]" instead (i.e.,
controller.enqueue(encoder.encode(`2:[${JSON.stringify(...)}]\n`))) so these
payloads populate useChat's data array and get returned by getToolResults(),
getInquiry(), etc.
- Around line 89-91: The streaming Response objects in this route (the four
occurrences that call "new Response(stream, { headers: { 'Content-Type':
'text/plain; charset=utf-8' } })") must include the required protocol header;
update each Response return to add "x-vercel-ai-data-stream": "v1" to the
headers alongside Content-Type so the AI SDK (useChat) can recognize and parse
the stream. Locate the four Response constructions in this file (the streaming
returns around the areas noted) and merge the headers into a single headers
object that includes both 'Content-Type' and 'x-vercel-ai-data-stream': 'v1'.
- Around line 297-317: The saveChatAsync flow is generating new nanoid() for
every message (in the messages -> aiMessages mapping) which breaks dbSaveChat's
onConflictDoUpdate deduping; update the mapping in route.ts to preserve message
identity by using msg.id when present (e.g., aiMessages.push uses msg.id) and
only call nanoid() for messages that lack an id, and ensure tool outputs keep
stable IDs similarly; alternatively (if preserving incoming ids isn't possible),
call the db routine to delete prior messages for the chat before inserting the
replayed history — reference the messages array, aiMessages, nanoid(),
saveChatAsync and dbSaveChat to locate the changes.
- Around line 187-192: The three fire-and-forget calls to saveChatAsync
(occurring just before returning streamed Responses) must be wrapped with
Next.js after() to ensure the DB write completes after the response is sent;
replace direct calls like saveChatAsync(chatId, userId, ...) with after(() =>
saveChatAsync(chatId, userId, messages, answer, allToolOutputs, relatedQueries))
for each occurrence (the saveChatAsync invocations in the streaming route
handlers) so the runtime will wait for the save to finish even in serverless
environments.
- Line 80: The stream termination currently enqueues only an "e:" finish-step
and immediately closes the controller (see usages of
controller.enqueue(encoder.encode(...)) and controller.close()), which omits the
required "d:" finish-message; after each existing e: message emit a second
controller.enqueue(encoder.encode(...)) that sends the "d:" chunk with the same
finishReason and usage payload (matching the existing e: content) and then call
controller.close(); update all four occurrences where e: is emitted so useChat
receives the final d: message before stream close.

In `@app/search/`[id]/page.tsx:
- Around line 41-46: The initialMessages mapping drops annotations (and possible
toolInvocations), and unsafely casts dbMsg.role, causing
ToolResultRenderer/getToolResults and SearchRelated/getRelatedQueries to have no
data and useChat to get invalid roles; update the mapping in initialMessages to
include annotations and toolInvocations from dbMsg (rehydrate the JSONB column
you added to messages) and validate dbMsg.role against the allowed Message roles
used by useChat (e.g., check against a set like
['user','assistant','system','tool'] and fallback to a safe default) so
annotations are preserved and role values are constrained.

In `@components/chat-messages.tsx`:
- Around line 29-36: The code duplicates provider logic by re-filtering
annotations into toolAnnotations; instead call the provider helper
getToolResults(...) (from the context exposed in chat-provider via
getToolResults) to obtain tool results, then iterate those results to push
entries into renderedMessages with id, component (ToolResultRenderer) and
isCollapsed. Remove the local annotations.filter(...) and use getToolResults to
keep logic centralized and consistent.
- Around line 104-114: The isLastMessage prop is computed from index ===
renderedMessages.length - 1 which can point at inquiry/related/tool rows;
instead, compute the index of the final assistant text/turn when building
renderedMessages and pass isLastMessage only for that assistant message row.
Locate where renderedMessages is created and where CollapsibleMessage is
rendered, determine the last assistant message by scanning renderedMessages for
assistant-type entries (e.g., entries with role/type identifying assistant text)
to get lastAssistantIndex, then change the prop to isLastMessage={index ===
lastAssistantIndex} so only the true assistant response controls
auto-expansion/streaming in CollapsibleMessage.
- Around line 22-36: The keys for ToolResultRenderer are unstable because they
use Math.random(), causing remounts; change the id generation in the
renderedMessages push (the block that builds toolAnnotations and pushes entries
into renderedMessages) to use a stable identifier instead of Math.random()—for
example use an existing annotation unique field (like ann.id), or derive a
deterministic key from ann.toolName plus the annotation index or a hash of
ann.result, and ensure that same stable id is passed as the key to
ToolResultRenderer so React reconciliation preserves component state.
- Around line 77-100: Replace the dynamic require() calls inside the render with
static imports at the top: import Copilot, SearchRelated (or its named export)
and Section (named) instead of using require('./copilot'),
require('./search-related').default and require('./section'); update the
renderedMessages entries to use the imported Copilot, SearchRelated and Section
directly (remove the SectionComp alias), and if you need runtime code-splitting
use next/dynamic to import SearchRelated/Copilot with ssr: false rather than
require() so bundlers and RSC static analysis work correctly.

In `@components/chat-panel.tsx`:
- Around line 30-31: Remove the redundant messages prop from the ChatPanel
component and read messages directly from the context returned by
useChatContext(); specifically, update the ChatPanel signature to drop the
messages parameter and any prop type that includes messages, then replace usages
of the prop with the messages value from const { append, setMessages, messages }
= useChatContext() (or similar) inside the ChatPanel body, and update any
callers to stop passing messages into ChatPanel so there is a single source of
truth.
- Around line 107-110: The handleClear function only calls setMessages([]) and
clearAttachment(), which leaves the current chatId in ChatProvider intact so
subsequent append calls continue writing to the same server-side chat record;
update handleClear to either (A) remount ChatProvider with a fresh chatId by
navigating to a new route (e.g., push('/') or generate a new /search/[newId] and
navigate) so a new server chat is created, or (B) call the server-side
clearChat/delete API for the active chatId before clearing local state; modify
the handleClear implementation (and any callers of setMessages/clearAttachment)
to perform one of these two flows and ensure chatId is reset or the server
record deleted to keep client and server histories in sync.

In `@components/chat-provider.tsx`:
- Around line 59-65: The current annotations const casts useChat().data to
Annotation[] unsafely and ignores that most annotations are emitted under the
route's "8:" message-annotation frames (so annotations will be empty); update
the logic used by annotations and getToolResults to (1) treat useChat().data as
JSONValue[] at runtime and filter with a type guard that verifies each entry is
an Annotation object (has a string "type" and other expected fields) before
casting, and (2) also extract annotations from message frames (entries shaped
like { type: 'message', message: { annotations: [...] } }) so
message.annotations are included; adjust getToolResults to operate on this
validated combined list (refer to useChat().data, the annotations const, and
getToolResults to locate where to change).
- Around line 77-97: The ChatContext.Provider's value object is recreated on
every render causing unnecessary re-renders; wrap the value passed to
<ChatContext.Provider> in a useMemo and list its dependencies (messages, input,
setInput, handleSubmit, append, setMessages, isLoading, chatId, annotations,
getToolResults, getInquiry, getRelatedQueries) so the object identity only
changes when those actual values change; update the component to import/use
React.useMemo and replace the inline value={{...}} with a memoized value
variable used in the Provider.
- Around line 13-26: The ChatContextValue.append signature is too narrow and
uses an any cast; update ChatContextValue to match the SDK signature used by
useChat().append by changing append to accept (message: Message | CreateMessage,
options?: ChatRequestOptions) => Promise<string | null | undefined> and remove
any as any casts where append is forwarded; ensure imports/types for
CreateMessage and ChatRequestOptions are pulled from the SDK and update all
usages that relied on the previous restrictive shape (e.g., callers sending
body: { action: 'resolution_search', fileData }) to compile with the new types.

In `@components/chat.tsx`:
- Around line 70-75: The effect calling router.refresh() fires on mount when the
last persisted message is from the assistant; change the condition to only
refresh when a streaming response just finished by tracking the previous
isLoading state (e.g., a useRef prevIsLoading) and require prevIsLoading ===
true && isLoading === false in the useEffect that inspects messages and
lastMsg.role === 'assistant' before calling router.refresh(); update the
useEffect dependency list accordingly and set prevIsLoading = isLoading at the
end of the effect so only transitions from loading→not-loading trigger the
refresh.

In `@components/collapsible-message.tsx`:
- Around line 28-33: The useEffect currently lists isCollapsed as a dependency
but always resets open to isLastMessage, which overrides user toggles when
isCollapsed changes; update the effect on the component that uses
isCollapsed/open/setOpen/useEffect/isLastMessage so it only responds to changes
in isLastMessage (remove isCollapsed from the dependency array) so open is only
programmatically reset when the message becomes the last message, preserving
user-controlled toggles when isCollapsed flips.

In `@components/copilot.tsx`:
- Around line 69-73: The current code appends the skip sentinel as a visible
user message (append({ role: 'user', content: '{"action": "skip"}' })), which
leaks into UI and persisted chat history; instead send the sentinel as metadata
using the body option (following the drawnFeatures pattern in
followup-panel.tsx) so it isn't rendered or stored as a user-visible
message—update the append call in components/copilot.tsx to append the real user
content (or updatedQuery()) and pass { body: { action: 'skip' } } (or similar)
to convey the skip intent, and ensure any server-side stream/route handler reads
the body metadata rather than relying on message content.

In `@components/followup-panel.tsx`:
- Around line 15-28: The handleSubmit function currently calls append(...)
without error handling and allows duplicate submissions; wrap the append call in
a try/catch/finally inside handleSubmit (use a local submitting state or the
context flag useChatContext().isLoading) to prevent concurrent submissions, set
a submitting boolean true before calling append and false in finally, show or
propagate an error (e.g., set an error state or call a provided notify) from the
catch, and only clear the input via setInput('') on success; also disable the
submit button when submitting or useChatContext().isLoading to guard against
duplicate sends.

In `@components/header-search-button.tsx`:
- Line 160: The button's disabled check uses map from useMap() (Mapbox) and thus
disables the control when mapProvider === 'google' even though
handleResolutionSearch supports Google via mapData.cameraState; update the
disabled expression to be provider-aware (e.g. keep isAnalyzing, then require
map only for Mapbox and require mapData?.cameraState for Google) and apply the
identical change to the mobile button; modify the components using map,
mapProvider, mapData and isAnalyzing so that disabled becomes something like:
disabled={isAnalyzing || (mapProvider === 'mapbox' && !map) || (mapProvider ===
'google' && !mapData?.cameraState)} ensuring you update both the desktop and
mobile button instances that reference disabled.
- Around line 117-128: Update blobToBase64 to handle errors by adding
reader.onerror to reject the Promise on failure and ensure it resolves only with
a non-null string; then avoid duplicate conversions by computing the base64 once
for the chosen blob and reusing it: compute a singleBase64 (using blobToBase64)
from (mapboxBlob || googleBlob) and assign that to fileData, and only compute
mapboxImageData or googleImageData separately if the other provider's blob is
present and different; adjust uses of fileData, mapboxImageData, and
googleImageData accordingly so a single blob isn't read twice.

In `@components/resolution-carousel.tsx`:
- Around line 40-44: The FileReader usage in resolution-carousel.tsx creates a
Promise that only resolves on reader.onloadend which can hang if readAsDataURL
fails; update the Promise in the code that creates fileData (the FileReader
block) to attach reader.onerror and reader.onabort handlers that reject the
Promise with the error/event, and ensure you call reader.onloadend only after
verifying reader.result is usable; also call reader.removeEventListener/clear
handlers or cancel the read on rejection to avoid leaks. By rejecting the
Promise on error/abort the outer await will throw and your existing try/finally
(and setIsAnalyzing(false)) will run as expected.

In `@components/search-related.tsx`:
- Around line 18-20: The related-query handler handleRelatedClick currently
calls append({ role: 'user', content: query }) which omits the same body context
(mapProvider, drawnFeatures) that ChatPanel.handleSubmit includes; update
handleRelatedClick to forward the same default body used by
ChatPanel/ChatProvider (include mapProvider and drawnFeatures along with chatId)
or move the default body construction into ChatProvider and call append with
that shared body so related queries receive the same tool/geospatial context;
reference functions/components: handleRelatedClick, ChatPanel.handleSubmit,
ChatProvider, and append, and ensure the appended payload includes mapProvider
and drawnFeatures fields.

In `@components/tool-result-renderer.tsx`:
- Around line 18-21: The code is doing an unnecessary JSON.stringify/parse
round-trip when rendering search results; update the components to accept the
typed object directly instead of a string: change SearchSection and
VideoSearchSection props from result?: string to result?: TypeSearchResults |
SerperSearchResults (or the appropriate concrete types), update their internal
usages to consume the object type (remove parsing), and then in
components/tool-result-renderer.tsx return <SearchSection result={result} /> and
<VideoSearchSection result={result} /> (also update any other call sites and
imports/types to match the new prop signatures).
- Around line 17-23: ToolResultRenderer must short-circuit error-shaped tool
outputs before dispatching to sections: detect the error shape from the incoming
result (either result?.error for objects or, for the search/video paths where
you stringify, parse the string safely and check for an "error" field) inside
the ToolResultRenderer switch/dispatch logic and return an error UI (or a simple
error message) instead of rendering SearchSection, VideoSearchSection, or
RetrieveSection; reference the toolName switch and the result variable and
handle both object and JSON-stringified error payloads so SearchSection,
VideoSearchSection, and RetrieveSection never receive the { error: string }
shape.

In `@components/video-search-section.tsx`:
- Around line 13-14: The component VideoSearchSection currently calls
JSON.parse(result) directly which can throw and crash the render; wrap the parse
in a try/catch inside VideoSearchSection (protecting the result value) so that
if parsing fails you set searchResults to undefined (or an explicit error flag)
and log the error, then render the existing skeleton/error UI path instead of
letting the exception bubble; update references to searchResults (and any
downstream rendering that expects SerperSearchResults) to handle the fallback
case safely.

In `@lib/actions/suggest.ts`:
- Around line 26-41: Replace the streaming usage with the final-value primitive:
stop calling streamObject and use generateObject to return a single
Promise<PartialRelated> (use generateObject with systemPrompt, messages [{ role:
'user', content: query }], and relatedSchema) and remove the for-await loop that
only kept the last partial; also ensure the model passed from getModel() is an
OpenAI model that supports structured outputs (e.g., gpt-4o) before calling
generateObject—validate or coerce the result of getModel() into a compatible
LanguageModel and throw/log a clear error if an incompatible model (like X.AI
grok) is returned.

In `@lib/agents/inquire.tsx`:
- Around line 8-37: The current implementation uses streamObject(...) and
iterates partialObjectStream to set finalInquiry, which only yields the terminal
object and hides partial state; replace streamObject with generateObject
(passing the same params: model (await getModel()) as LanguageModel, system
prompt, messages, schema: inquirySchema) and await its returned object directly,
then assign that result to finalInquiry and return it, removing the for-await
loop over partialObjectStream; ensure types for finalInquiry and the
generateObject call align with PartialInquiry.

In `@lib/agents/tools/geospatial.tsx`:
- Around line 275-283: The switch over queryType inside the IIFE can return
undefined for unknown query types; change the switch in the IIFE (the block that
currently calls prefer('directions_tool') / prefer('matrix_tool') / etc.) to
include a default case that throws a structured Error (or a custom Error
subclass) indicating the queryType is unsupported (include the queryType value
in the message), and then remove the downstream fallback that uses toolName ??
'unknown_tool' so we fail fast and surface a clear "unsupported queryType" error
instead of sending "unknown_tool" to the MCP server.

In `@lib/agents/writer.tsx`:
- Line 16: The default system prompt string containing the typo "There are also
some proconfigured example queires." should be updated: find the prompt literal
in lib/agents/writer.tsx that includes that exact phrase and replace
"proconfigured" with "preconfigured" and "queires" with "queries" so the prompt
reads "There are also some preconfigured example queries."

---

Outside diff comments:
In `@app/actions.tsx`:
- Around line 1-9: The file exports only the AIState type (referencing
AIMessage) and is unused and misnamed as a .tsx; either delete app/actions.tsx
or move the AIState type into the existing types module where AIMessage lives
(e.g., add export type AIState = { messages: AIMessage[]; chatId: string;
isSharePage?: boolean } to the types file and remove the redundant file), and
update any imports if you relocate the type.

In `@components/chat-panel.tsx`:
- Around line 86-105: handleSubmit currently clears selectedFile via
clearAttachment() and only appends the user text; modify handleSubmit to include
the attached file by base64-encoding selectedFile and passing it as fileData in
the append call body alongside mapProvider and drawnFeatures, and include
action: 'resolution_search' so the backend route (app/api/chat/stream) can
process the file; ensure you still clearAttachment() and setInput('') after the
append completes, and keep the submit enabled when only a file is attached by
using the existing selectedFile check.

In `@components/mobile-icons-bar.tsx`:
- Around line 42-44: handleNewChat currently only calls setMessages([]) which
leaves the user on the old /search/[oldId] so subsequent messages append to the
previous chat; update handleNewChat (remove the unnecessary async) to also
navigate away so a fresh chatId is created — either call router.push('/') after
clearing messages or generate a new id and call router.push(`/search/${newId}`)
(keep setMessages([]) as-is), ensuring you reference the handleNewChat function
and the Chat component's routing behavior when making the change.

In `@components/search-section.tsx`:
- Around line 14-39: Wrap the JSON.parse in SearchSection with a try/catch and
fall back to a safe undefined/parseError state instead of letting a thrown parse
error bubble out; after parsing, explicitly check for an error shape (e.g.,
searchResults?.error) and render an error branch (for example show a ToolBadge
or a Section with the error message) rather than attempting to use
searchResults.query, searchResults.images, or searchResults.results when they
may be undefined; update the JSX branches in SearchSection to use the parseError
/ error-object checks so SearchResultsImageSection and SearchResults only
receive valid arrays/strings.

In `@lib/agents/researcher.tsx`:
- Around line 134-143: The researcher function currently mutates the caller's
messages array by pushing the assistant turn and tool responses (see messages,
toolCalls, toolResponses, fullResponse), causing retries to compound context;
change researcher to avoid in-place mutation by building and returning the new
message segments (e.g., newSegments containing the assistant message and any
tool messages) instead of pushing into messages, update the return to include
those segments (alongside result, fullResponse, hasError, toolResponses), and
let the caller decide whether to append newSegments to messages (only after a
successful, non-empty fullResponse) or to reset messages before retries.

In `@lib/agents/tools/geospatial.tsx`:
- Around line 37-41: The console.log in the GeospatialTool environment check is
leaking secret prefixes by printing substrings of composioApiKey,
mapboxAccessToken, and composioUserId; change this to log only boolean presence
checks (e.g., !!composioApiKey, !!mapboxAccessToken, !!composioUserId) or
descriptive status strings like "present"/"missing" in the same console.log call
so no parts of secrets are emitted (locate the block referencing composioApiKey,
mapboxAccessToken, composioUserId and replace the substring masking with
presence indicators).
- Around line 50-57: Replace the dynamic require of the mapbox JSON and the
redundant try/catch with a static JSON import using the project's
resolveJsonModule support: remove the require('../../../mapbox_mcp_config.json')
call and the surrounding try/catch, statically import the JSON
(mapbox_mcp_config.json) at the top of the module, drop the unused local
variable config and/or mapboxMcpConfig if not used elsewhere, and use the
imported object directly where needed (referencing mapbox_mcp_config.json and
any code that previously referenced mapboxMcpConfig or config).

In `@lib/agents/tools/index.tsx`:
- Around line 12-24: The tools object in getTools is typed as any which loses
compile-time guarantees; replace tools: any with a stronger type such as the
SDK's ToolSet (from 'ai') or a union Record type using ReturnType for each
factory (e.g., Record<string, ReturnType<typeof searchTool> | ReturnType<typeof
retrieveTool> | ReturnType<typeof videoSearchTool> | ReturnType<typeof
geospatialTool>>) so streamText({ tools }) and other callers get proper type
checking; update the signature of getTools (and ToolProps if needed) to reflect
the chosen type.

In `@lib/agents/tools/retrieve.tsx`:
- Around line 9-35: The catch path is coercing the Error object into a string
and the fetch has no status or timeout handling; update the fetch call (where
you call fetch(`https://r.jina.ai/${url}`) and call response.json()) to use an
AbortController with a short timeout (e.g., 5s), check response.ok and return a
clear error when status is not ok (include response.status and statusText),
safely parse JSON with a try/catch and handle non-JSON bodies, and in the catch
block return the actual error.message (and error.cause if present) rather than
using `${error}` so the returned error includes the real message and URL.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/api/chat/stream/route.ts`:
- Around line 320-374: The synthetic rows pushed into aiMessages (see the
toolOutputs loop, the block adding answer, relatedQueries, and the final 'end'
marker) use fresh nanoid() each save, causing duplicate rows; change those id
generations to deterministic IDs derived from the chat context (e.g., use chatId
+ turnIndex + role/type like `${chatId}:${turnIndex}:response`) or only persist
the current turn's delta instead of re-writing all messages so
onConflictDoUpdate(id) will match existing rows; update the id assignment for
the tool output block (tool.toolName), the assistant answer block, the
related-queries block, and the end marker to use that deterministic scheme.
- Around line 75-98: The hardcoded reply branch using lastText exact matches
(variable lastText) is fragile and bypasses taskManager/RAG/tool persistence
while saving only the raw definition via saveChatAsync; fix by normalizing the
input (e.g., strip punctuation and whitespace and lowercase lastText) or better
yet move these canned definitions into the system prompt/source-of-truth, and
ensure the branch funnels responses through the same pipeline as other chats:
invoke taskManager or the normal response composer so RAG augmentation and tool
outputs are applied, and when persisting use the same save path (e.g.,
saveChatAsync) but include the full response metadata (related queries/tool
outputs) rather than only the raw definition so rehydrated history contains
relatedQueries and usage fields; locate changes around lastMsg/lastText
handling, the conditional block that constructs definition and the call to
saveChatAsync to implement this.
- Around line 217-298: The stream's start callback in handleResolutionSearch can
throw without reaching the outer catch and leaves useChat stuck; wrap the entire
start(controller) body in a try/catch and on error call controller.error(err) or
enqueue synthetic finish frames (e: and d: with finishReason:"error") before
closing so the client receives a terminal event; also stop doing fire-and-forget
saveChatAsync(...) — schedule it via after(() => saveChatAsync(chatId, userId,
messages, analysisResult.summary || '')) (or the equivalent after wrapper used
elsewhere) so the save runs safely in the serverless background.
- Around line 53-64: The current in-place splice and aggressive filter/map
remove tool turns and mutate messages used later for title heuristics: instead
of mutating messages with messages.splice(...) create a trimmed copy (e.g.,
trimmedMessages = messages.slice(-maxMsgs)) so the original array (and original
first user message) remains intact; when building messages preserve tool turns
and toolInvocations by including role === 'tool' and copying m.toolInvocations
in the map that produces CoreMessage (rather than dropping those fields);
finally pass the preserved originalFirstUserMessage (capture messages[0] before
trimming) into saveChatAsync for title computation so the title heuristic uses
the original user prompt.
- Around line 168-176: relatedQueries is left as {} when errorOccurred and then
emitted unconditionally, wasting bandwidth; change logic so relatedQueries is
only set and streamed when querySuggestor returned non-empty results.
Specifically: keep using the sanitizedMessages -> querySuggestor(...) call but
set relatedQueries to undefined/null by default, and when emitting the
annotation that currently sends { type: 'related', relatedQueries } only do so
if !errorOccurred && relatedQueries?.items?.length > 0; update the emission code
that writes the { type: 'related', relatedQueries } annotation to be conditional
on that check.

In `@components/chat-messages.tsx`:
- Line 18: The variable isLoading is currently unused after destructuring from
useChatContext(); either remove it from the destructuring to eliminate the
unused variable, or thread it into the message rendering so loading state can be
shown — e.g., pass isLoading as a prop into CollapsibleMessage (or the assistant
skeleton component used to render assistant messages) and use it to show the
streaming/loading indicator there; update the useChatContext() destructure in
components/chat-messages.tsx and the CollapsibleMessage/assistant component
props and handling accordingly.
- Around line 31-40: Tool result annotations are being rendered globally from
annotations (useChat().data) causing old tool outputs to accumulate; either have
the backend include a per-message identifier (e.g., messageId or turnIndex on
tool_result) and then filter annotations by that id before pushing to
renderedMessages, or stop rendering all tool_result entries up-front and instead
render tool outputs inside the per-message loop (use message.toolInvocations or
the current message object) so you only render tool results that belong to the
current assistant message; update the rendering logic around the annotations
variable and the ToolResultRenderer invocations (and adjust where
renderedMessages is populated) to use the per-message identifier or
message.toolInvocations to scope tool results.

In `@components/chat-panel.tsx`:
- Around line 99-128: The FileReader promise in handleSubmit (creation of
FileReader, reader.onloadend/reader.onerror and awaiting new Promise) must be
wrapped in try/catch so reader.onerror rejections are handled; on error,
log/report a user-visible error (e.g., set an error state or show a toast),
avoid calling setInput('')/clearAttachment() or restore them if already cleared,
and return early so append(...) is not called; update the block around
FileReader/reader.onerror and the subsequent setInput/clearAttachment calls to
only run after a successful read and ensure append(...) is only invoked when
fileData is available or when no file, keeping existing append(...) usage
intact.

In `@components/chat-provider.tsx`:
- Line 22: Update the handleSubmit signature in the chat provider interface to
use the proper ChatRequestOptions type instead of any: change handleSubmit: (e?:
React.FormEvent<HTMLFormElement>, options?: any) => void to accept options?:
ChatRequestOptions; ensure you import or reference ChatRequestOptions from the
SDK/module where other request types come from (matching existing imports),
update any related usages/calls to satisfy the stronger type, and run typechecks
to fix any mismatches.
- Around line 47-67: The ChatProvider currently ignores useChat's error and
control callbacks so 401s and stream failures are swallowed; update ChatProvider
to extract error, reload and stop (and optionally onError/onResponse handlers)
from useChat and include them in the memoized context value and ChatContextValue
type so consumers (e.g., ChatMessages/ChatPanel) can show a toast/banner on
error and provide retry/stop controls; ensure the memoized value returned by
ChatProvider contains error, reload, and stop alongside
messages/input/append/handleSubmit/isLoading/data.

In `@components/video-search-section.tsx`:
- Line 28: The render currently accesses searchResults.searchParameters.q
directly which can throw if searchParameters is missing; update the usage inside
ToolBadge (component: ToolBadge) to use optional chaining and a safe fallback
(e.g., searchResults?.searchParameters?.q ?? '' or a placeholder like '—') so
rendering remains robust against partial/malformed payloads while keeping the
rest of the JSX unchanged.

In `@lib/agents/researcher.tsx`:
- Around line 134-145: newSegments can include tool-calls without matching
tool-results when a stream errors after a 'tool-call' but before its
'tool-result', and also can create an assistant message with empty text when
fullResponse is empty; fix by filtering toolCalls to only include those that
have a corresponding toolResult (match by the ToolCallPart/ToolResultPart
identifier — verify and use toolCallId if present, otherwise toolName) before
building newSegments, and skip adding an assistant text part when fullResponse
is empty; update the logic around the variables newSegments, toolCalls,
toolResponses, ToolCallPart, ToolResultPart, fullResponse, and the errorOccurred
handling so only paired tool-call/tool-result entries are appended to message
history.

In `@lib/agents/writer.tsx`:
- Around line 22-35: Replace the nonexperimental_streamText usage and manual
for-await reassembly with generateText: call generateText({ model: await
getModel() as LanguageModel, maxTokens: 2500, system: systemToUse, messages })
await its result and return the returned full text directly instead of looping
over result.textStream and concatenating into fullResponse; remove the
fullResponse variable and the for-await loop around nonexperimental_streamText.

---

Outside diff comments:
In `@lib/agents/tools/geospatial.tsx`:
- Around line 270-300: The code currently falls back to name: 'unknown_tool'
when toolName is undefined, masking missing MCP tool mappings; update the
toolName resolution (the IIFE that calls prefer(...)) to detect when prefer(...)
returns undefined and immediately throw a clear, structured Error (including
queryType and the attempted tool identifiers) instead of returning undefined,
and remove the "?? 'unknown_tool'" fallback from the mcpClient.callTool call so
mcpClient.callTool({ name: toolName, arguments: toolArgs }) is only invoked with
a validated toolName; reference prefer(), toolName, and mcpClient.callTool to
locate the changes.

---

Duplicate comments:
In `@components/followup-panel.tsx`:
- Around line 17-37: The handler clears the input before awaiting append,
causing user text to be lost on failure; in handleSubmit, keep the trimmed
content in a local variable (content) and either move setInput('') to after the
awaited append succeeds or restore the input in the catch by calling
setInput(content); also replace the console.error with a UI-facing error state
(e.g., setError) or show a toast so users see failures—update references to
handleSubmit, append, setInput, and mapData.drawnFeatures accordingly.

In `@components/header-search-button.tsx`:
- Around line 128-130: The code converts the same blob to base64 multiple times;
change the order to compute mapboxImageData = mapboxBlob ? await
blobToBase64(mapboxBlob) : undefined and googleImageData = googleBlob ? await
blobToBase64(googleBlob) : undefined once, then set fileData = mapboxImageData
?? googleImageData (or otherwise reuse the already-computed base64) so that
blobToBase64 is not called twice for the same blob; update references to
fileData, mapboxImageData, googleImageData and keep using blobToBase64,
mapboxBlob and googleBlob identifiers to locate the change.

In `@components/search-related.tsx`:
- Around line 20-29: The related-query handler handleRelatedClick currently only
sends mapProvider in the append() body; include the same geospatial context
fields that the route expects (drawnFeatures, timezone, latitude, longitude) so
follow-ups carry user-drawn map context—either add those properties to the body
passed in handleRelatedClick or centralize a default request body in
ChatProvider so all append() calls (including ChatPanel.handleSubmit and
handleRelatedClick) inherit drawnFeatures/timezone/latitude/longitude along with
mapProvider.